home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / partis256 < prev    next >
Encoding:
Text File  |  1992-11-30  |  6.4 KB  |  154 lines
  1. So all the text files out there in the world already fit the role of a
  2. MIME body part. They don't need any headers, encodings, or anything.
  3. In fact, all the non text files qualify as MIME body parts too, if we
  4. associate them with the application/octet-stream content-type and the
  5. binary content-transfer-encoding.
  6.  
  7. A MIME message is actually a special case of the body part concept.
  8. Along with the text/plain, image/gif, audio/basic,
  9. application/postscript etc. types, there's a message/rfc-822 type.
  10. That's where the headers and stuff come in.
  11.  
  12. There's also a multipart/mixed type that encapsulates several body
  13. parts into one. It has some syntax that a lot of folks aren't crazy
  14. about, but it's just _one_type_ of body part.
  15.  
  16.  
  17.     EIGHT BIT DATA, ENCODINGS, AND TRANSPORT
  18.  
  19. The other area of confusion concerns eight bit data. MIME provides
  20. mechanisms for transport of eight bit data across mail transport
  21. agents that only grok limited character sets and line lengths. These
  22. mechanisms obviously increase the size of messages.
  23.  
  24. But when used with 8-bit-clean transport mechanisms, the encodings are
  25. not necessary, and MIME adds no cost to data transport. From the RFC:
  26.  
  27.     As of the publication of this document, there are no
  28.     standardized Internet transports for which it is legitimate
  29.         to include unencoded 8-bit or binary data in mail bodies.
  30.         Thus there are no circumstances in which the "8bit" or "binary"
  31.         Content-Transfer-Encoding is actually legal on the Internet.
  32.         However, in the event that 8-bit or binary mail transport
  33.         becomes a reality in Internet mail, or when this document
  34.                                             ^^^^^^^^^^^^^^^^^^^^^
  35.         is used in conjunction with any other 8-bit or binary-capable
  36.         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  37.         transport mechanism, 8-bit or binary messages should be labeled
  38.         ^^^^^^^^^^^^^^^^^^^
  39.         as such using this mechanism.
  40.  
  41. That is, the MIME standard suggests that 8-bit data be labelled as
  42. such, so that gateways between 8-bit and 7-bit systems can recognize
  43. and encode such data.
  44.  
  45. For example: a WAIS<->email gatway might retrieve a GIF image from a
  46. WAIS server. If the WAIS server stated that the data is type image/gif
  47. and binary encoded, the gateway could base64 encode the data and send
  48. it on its way through SMTP. On the other hand, if the server labelled
  49. the data 7bit text/plain, the gateway could pass it along without
  50. encoding.
  51.  
  52.  
  53.     GOPHER SUPPORT FOR MIME
  54.  
  55. Gopher defines several types of "objects." The basic types are text
  56. files and directories. Other types include various archive formats,
  57. telnet sessions, CSO servers, raw data files, and a few experimental
  58. types.
  59.  
  60. One of the experimental types is 'M' for MIME messages, that is body
  61. parts of type message/rfc-822. I suppose that much of the opposition
  62. to using the MIME body part to model the Gopher object comes from
  63. folks who think that they'd have to put all their data into
  64. message/rfc-822 format.
  65.  
  66. But I didn't suggest we use the MIME message/rfc-822 format for all
  67. Gopher objects: just use _some_ MIME format for all gopher objects.
  68. The fact is, their data is already in a MIME format: text/plain. And
  69. the experimental 'g' (GIF) type is already a MIME type: image/gif.
  70.  
  71. The only Gopher objects that don't fit the MIME system are the ones
  72. that are not data streams at all: telnet sessions, CSO servers, etc. I
  73. don't know how (or if) they fit into the MIME model.
  74.  
  75. There are some Gopher objects that fit the MIME model but are not part
  76. of the MIME standard (yet). For example, the directory listing that
  77. gopher servers send back could be called application/x-gopher for now,
  78. and eventually application/gopher (when it's spec'd out and registered
  79. with the IANA.)
  80.  
  81. The gopher protocol can be enhanced one time to support the myriad of
  82. multimedia data formats by including a content-type field in gopher
  83. listings.
  84.  
  85. The Gopher+ protocol has even more in common with MIME. In Gopher+,
  86. each gopher object has a bunch of ancillary information such as the
  87. maintainer, size, format, etc. A Gopher+ object and its ATTRIBUTES
  88. looks an awful lot like a MIME body part and it's encapsulating
  89. message. It seems a waste to define two competing standards for the
  90. same mechanisms.
  91.  
  92.  
  93.     WAIS SUPPORT FOR MIME
  94.  
  95. A WAIS document looks like a MIME body part too: a sequence of bytes
  96. with a type. The canonical WAIS type is TEXT. And like the type 'M'
  97. support in gopher, somebody hacked in support for a MIME type in WAIS.
  98.  
  99. Again, I suggest that the MIME typing system be used in stead of,
  100. rather than inside, the WAIS typing system. That is, modify the
  101. Document-id Structure Definition so that
  102.  
  103. :type <string>
  104.  
  105. is obsoleted by 
  106.  
  107. :content-type <string> ;; as defined by RFC-1341
  108.  
  109. The only two supported types are TEXT and SRC, whic translate neatly
  110. to text/plain and application/x-wais-src.
  111.  
  112.  
  113.     WWW SUPPORT FOR MIME
  114.  
  115. There was a question on www-talk about non-text data in WWW documents.
  116. It seems clear that using MIME body parts to model WWW documents is a
  117. natural step.
  118.  
  119. The notion of a WWW address should be expanded to what I would call a
  120. reference, which is an address, a content-type, and any identification
  121. information (so that clients can test whether two references point to
  122. the same document.)
  123.  
  124. The WWW client currently infers the content-type from the address. For
  125. the file: scheme, an .html extension implies HTML format -- other wise
  126. text is assumed. Documents from HTTP servers are HTML, which slams
  127. plain text inside SGML if necessary. Documents from Gopher servers are
  128. either plain text or gopher listings. I don't know what WWW clients do
  129. with WAIS documents that aren't text.
  130.  
  131.  
  132.     FROM GLOBAL HYPERTEXT TO GLOBAL HYPERMEDIA
  133.  
  134. The Internet currently serves as the backbone for a global hypertext.
  135. FTP and email provided a good start, and the gopher, WWW, or WAIS
  136. clients and servers make wide area information browsing simple. These
  137. systems even interoperate, with email servers talking to FTP servers,
  138. WWW clients talking to gopher servers, on and on.
  139.  
  140. This currently works quite well for text.  But what should WWW clients
  141. do as Gopher and WAIS servers begin to serve up pictures, sounds,
  142. movies, spreadsheet templates, postscript files, etc.? It would be a
  143. shame for each to adopt its own multimedia typing system.
  144.  
  145. If they all adopt the MIME typing system (and as many other features
  146. from MIME as are appropriate), we can step from global hypertext to
  147. global hypermedia that much easier.
  148.  
  149.  
  150.     READ IT YOURSELF
  151.  
  152. Attached is the text of the MIME RFC. Enjoy.
  153.  
  154.